We will discuss accessors, member functions that get and set the values of fields (fields/properties) in greater detail in a following chapter. The naming conventions for accessors, however, are summarized below.

Getters

Getters are member functions that return the value of a field. You should prefix the word . get. to the name of the field, unless it is a boolean field and then you prefix . is. to the name of the field instead of . get..

Examples:

getFirstName()

getAccountNumber()

isPersistent()

isAtEnd()

By following this naming convention you make it obvious that a member function returns a field of an object, and for boolean getters you make it obvious that it returns true or false. Another advantage of this standard is that it follows the naming conventions used by the beans development kit (BDK) for getter member functions [DES97]. The main disadvantage is that . get. is superfluous, requiring extra typing.

Alternative Naming Convention for Getters . Has and Can

A viable alternative, based on proper English conventions, is to use the prefix . has. or . can. instead of . is. for boolean getters. For example, getter names such as hasDependents() and canPrint() make a lot of sense when you are reading the code. The problem with this approach is that the BDK will not pick up on this naming strategy (yet). You could rename these member functions isBurdenedWithDependents() and isPrintable().

Setters

Setters, also known as mutators, are member functions that modify the values of a field. You should prefix the word . set. to the name of the field, regardless of the field type.

Examples:

setFirstName(String aName)

setAccountNumber(int anAccountNumber)

setReasonableGoals(Vector newGoals)

setPersistent(boolean isPersistent)

setAtEnd(boolean isAtEnd)

Following this naming convention you make it obvious that a member function sets the value of a field of an object. Another advantage of this standard is that it follows the naming conventions used by the beans development kit (BDK) for setter member functions [DES97]. The main disadvantage is that . set. is superfluous, requiring extra typing.

Naming Constructors

Constructors are member functions that perform any necessary initialization when an object is first created. Constructors are always given the same name as their class. For example, a constructor for the class Customer would be Customer(). Note that the same case is used.

Examples:

Customer()

SavingsAccount()

PersistenceBroker()

This naming convention is set by Sun and must be strictly adhered to.

Member Function Visibility

For a good design where you minimize the coupling between classes, the general rule of thumb is to be as restrictive as possible when setting the visibility of a member function. If a member function does not have to be public then make it protected, and if it does not have to be protected then make it private.

Visibility	Description	Proper Usage
public	A public member function can be invoked by any other member function in any other object or class.	When the member function must be accessible by objects and classes outside of the class hierarchy in which the member function is defined.
protected	A protected member function can be invoked by any member function in the class in which it is defined or any subclasses of that class.	When the member function provides behavior that is needed internally within the class hierarchy but not externally.
private	A private member function can only be invoked by other member functions in the class in which it is defined, but not in the subclasses.	When the member function provides behavior that is specific to the class. Private member functions are often the result of refactoring, also known as reorganizing, the behavior of other member functions within the class to encapsulate one specific behavior.

Documenting Member Functions

The manner in which you document a member function will often be the deciding factor as to whether or not it is understandable, and therefore maintainable and extensible.

The Member Function Header

Internal Documentation

In addition to the member function documentation, you also need to include comments within your member functions to describe your work. The goal is to make your member function easier to understand, to maintain, and to enhance.

There are two types of comments that you should use to document the internals of your codeC-style comments ( /* & */) and single-line comments ( // ). As discussed above, you should seriously consider choosing one style of comments for documenting the business logic of your code and one for commenting out unneeded code. It is suggested that you use single-line comments for your business logic, because you can use this style of comments both for full comment lines and for inline comments that follow at the end of a line of code. Use C-style comments to document out lines of unneeded code because it makes it easier to take out several lines with only one comment. Furthermore, because C-style comments look so much like documentation comments their use can be confusing, taking away from the understandability of your code. Therefore use them sparingly.

Internally, you should always document:

1. Control structures. Describe what each control structure, such as comparison statements and loops. You should not have to read all the code in a control structure to determine what it does, instead you should just have to look at a one or two line comment immediately preceding it.
2. Why, as well as what, the code does. You can always look at a piece of code and figure out what it does, but for code that is not obvious you can rarely determine why it is done that way. For example, you can look at a line of code and easily determine that a 5% discount is being applied to the total of an order. That is easy. What is not easy is figuring out WHY that discount is being applied. Obviously there is some sort of business rule that says to apply the discount, so that business rule should at least be referred to in your code so that other developers can understand why your code does what it does.
3. Local variables. Although we will discuss this in greater detail in chapter 4, each local variable defined in a member function should be declared on its own line of code and should usually have an inline comment describing its use.
4. Difficult or complex code. If you find that you either can. t rewrite it, or do not have the time, then you must document thoroughly any complex code in a member function. A general rule of thumb is that if your code is not obvious, then you need to document it.
5. The processing order. If there are statements in your code that must be executed in a defined order then you should ensure that this fact gets documented [AMB98]. There. s nothing worse than making a simple modification to a piece of code only to find that it no longer works, then spending hours looking for the problem only to find that you have gotten things out of order.

Document Your Closing Braces Every so often you will find that you have control structures within control structures within control structures. Although you should avoid writing code like this, sometimes you find that it is better to write it this way. The problem is that it becomes confusing which ending brace, the } character, belongs to which control structure. The good news is that some code editors support a feature that when you select a open brace it will automatically highlight the corresponding closing one, the bad news is that not every editor supports this. I have found that by marking the ending braces with an inline comment such as //end if, //end for, //end switch, & makes your code easier to understand.

Techniques for Writing Clean Code

This section covers several techniques that help to separate the professional developers from the hack coders. These techniques are:

• Document your code
• Paragraph your code
• Use whitespace
• Follow the thirty-second rule
• Specify the order of message sends
• Write short, single command lines

Document Your Code

Remember, if your code is not worth documenting then it is not worth keeping[NAG95]. When you apply the documentation standards and guidelines proposed in this paper appropriately you can greatly enhance the quality of your code.

Paragraph/Indent Your Code

One way to improve the readability of a member function is to paragraph it, or in other words indent your code within the scope of a code block. Any code within braces, the { and } characters, forms a block. The basic idea is that the code within a block should be uniformly indented one unit.

The Java convention appears to be that the open brace is to be put on the line following the owner of the block and that the closing brace should be indented one level. The important thing as pointed out by [LAF97] is that your organization chooses an indentation style and sticks to it. Use the same indentation style that your Java development environment uses for the code that it generates.

Use Whitespace in Your Code A few blank lines, called whitespace, added to your Java code can help to make it much more readable by breaking it up into small, easy-to-digest sections. [VIS96] suggests using a single blank line to separate logical groups of code, such as control structures, with two blank lines to separate member function definitions. Without whitespace it is very difficult to read and to understand.

Follow The Thirty-Second Rule

Other programmers should be able to look at your member function and be able to fully understand what it does, why it does it, and how it does it in less than 30 seconds. If this is not possible then your code is too difficult to maintain and should be improved. Thirty seconds, that. s it. A good rule of thumb is that if a member function is more than a screen then it is probably too long.

Write Short, Single Command Lines

Your code should do one thing per line. Back in the days of punch cards it made sense to try to get as much functionality as possible on a single line of code. Whenever you attempt to do more than one thing on a single line of code you make it harder to understand. Why do this? We want to make our code easier to understand so that it is easier to maintain and enhance. Just like a member function should do one thing and one thing only, you should only do one thing on a single line of code.

Furthermore, you should write code that remains visible on the screen [VIS96]. You should not have to scroll your editing window to the right to read the entire line of code, including code that uses inline comments.

Specify the Order of Operations

A really easy way to improve the understandability of your code is to use parenthesis, also called "round brackets," to specify the exact order of operations in your Java code [NAG95]; [AMB98]. If you have to know the order of operations for a language to understand your source code then something is seriously wrong. This is mostly an issue for logical comparisons where you AND and OR several other comparisons together. Note that if you use short, single command lines as suggested above then this really should not crop up as an issue.

Standards For Fields (Fields/Properties)

The term field is here used to refer to a field, which the Beans Development Kit (BDK) calls a property [DES97]. A field is a piece of data that describes an object or class. Fields may be base data type like a string or a float, or may be an object such as a customer or bank account.

Naming Fields

You should use a full English descriptor to name your fields [GOS96]; [AMB98] to make it obvious what the field represents. Fields that are collections, such as arrays or vectors, should be given names that are plural to indicate that they represent multiple values.

Examples:

orderItems

Naming Components (Widgets)

For names of components (interface widgets) you should use a full English descriptor postfixed by the widget type. This makes it easy for you to identify the purpose of the component as well as its type, making it easier to find each component in a list (many visual programming environments provide lists of all components in an applet or application and it can be confusing when everything is named button1, button2, & ).

Examples:

newFileMenuItem

Alternative for Naming Components . Hungarian Notation

The "Hungarian Notation" [MCO93] is based on the principle that a field should be named using the following approach: xEeeeeeEeeeee where x indicates the component type and EeeeeEeeeee is the full English descriptor.

Examples:

The main advantage is that this is an industry standard common for C++ code so many people already follow it. Furthermore, developers can quickly judge from the name of the variable its type and how it is used. The main disadvantages are that the prefix notation becomes cumbersome when you have a lot of the same type of widget and you break from the full English descriptor naming convention.

Alternative for Naming Components . Postfix-Hungarian Notation

Basically a combination of the other two alternatives, it results in names such as okPb, customerLb, fileM, and newFileMi. The main advantage is that the name of the component indicates the widget type and that widgets of the same type are not grouped together in an alphabetical list. The main disadvantage is that you still are not using a full English description, making the standard harder to remember because it deviates from the norm.

Set Component Name Standards. Whatever convention you choose, you will want to create a list of "official" widget names. For example, when naming buttons do you use Button or PushButton, b or pb? Create a list and make it available to every Java developer in your organization

Naming Constants

In Java, constants, values that do not change, are typically implemented as static final fields of classes. The recognized convention is to use full English words, all in uppercase, with underscores between the words [GOS96].

Examples:

MINIMUM_BALANCE

MAX_VALUE

DEFAULT_START_DATE

The main advantage of this convention is that it helps to distinguish constants from variables. We will see later in the document that you can greatly increase the flexibility and maintainability of your code by not defining constants, instead you should define getter member functions that return the value of constants.

Naming Collections

A collection, such as an array or a vector, should be given a pluralized name representing the types of objects stored by the array. The name should be a full English descriptor with the first letter of all non-initial words capitalized.

Examples:

customers

orderItems

aliases

The main advantage of this convention is that it helps to distinguish fields that represent multiple values (collections) from those that represent single values (non-collections).

Field Visibility

When fields are declared protected there is the possibility of member functions in subclasses to directly access them, effectively increasing the coupling within a class hierarchy. This makes your classes more difficult to maintain and to enhance, therefore it should be avoided. Fields should never be accessed directly, instead accessor member functions (see below) should be used.

Visibility	Description	Proper Usage
public	A public field can be accessed by any other member function in any other object or class.	Do not make fields public.
protected	A protected field can be accessed by any member function in the class in which it is declared or by any member functions defined in subclasses of that class.	Do not make fields protected.
private	A private field can only be accessed by member functions in the class in which it is declared, but not in the subclasses.	All fields should be private and be accessed by getter and setter member functions (accessors).

For fields that are not persistent (they will not be saved to permanent storage) you should mark them as either static or transient [DES97]. This makes them conform to the conventions of the BDK.

Do Not "Hide" Names

Name hiding refers to the practice of naming a local variable, argument, or field the same (or similar) as that of another one of greater scope. For example, if you have a field called firstName do not create a local variable or parameter called firstName, or anything close to it like firstNames or fistName. This makes your code difficult to understand and prone to bugs because other developers, or you, will misread your code while they are modifying it and make difficult to detect errors.

Documenting a Field

Every field should be documented well enough so that other developers can understand it. To be effective, you need to document:

1. Its description. You need to describe a field so that people know how to use it.
2. Document all applicable invariants. Invariants of a field are the conditions that are always true about it. For example, an invariant about the field dayOfMonth might be that its value is between 1 and 31 (obviously you could get far more complex with this invariant, restricting the value of the field based on the month and the year). By documenting the restrictions on the value of a field you help to define important business rules, making it easier to understand how your code works.
3. Examples. For fields that have complex business rules associated with them you should provide several example values so as to make them easier to understand. An example is often like a picture: it is worth a thousand words.
4. Concurrency issues. Concurrency is a new and complex concept for many developers, actually, at best it is an old and complex topic for experienced concurrent programmers. The end result is that if you use the concurrent programming features of Java then you need to document it thoroughly.
5. Visibility decisions. If you have declared a field to be anything but private then you should document why you have done so. Field visibility is discussed in (section 3.2 "Field Visibility") above, and the use of accessor member functions to support encapsulation is covered in (section 3.4 "The Use of Accessor Member Functions") below. The bottom line is that you would better have a really good reason for not declaring a variable as private.

Using Accessor Member Functions

In addition to naming conventions, the maintainability of fields is achieved by the appropriate use of accessor member functions, member functions that provide the functionality to either update a field or to access its value. Accessor member functions come in two flavors: setters (also called mutators) and getters. A setter modifies the value of a variable, whereas a getter obtains it for you.

Although accessor member functions used to add overhead to your code, Java compilers are now optimized for their use, this is no longer true. Accessors help to hide the implementation details of your class. By having at most two control points from which a variable is accessed, one setter and one getter, you are able to increase the maintainability of your classes by minimizing the points at which changes need to be made. Optimization of Java code is discussed in (section 7.3 "Optimizing Java Code").

One of the most important standards that your organization can enforce is the use of accessors. Some developers do not want to use accessor member functions because they do not want to type the few extra keystrokes required (for example, for a getter you need to type in . get. and . (). above and beyond the name of the field). The bottom line is that the increased maintainability and extensibility from using accessors more than justifies their use.

Accessors Are The Only Place To Access Fields. A key concept with the appropriate use of accessor member functions is that the ONLY member functions that are allowed to directly work with a field are the accessor member functions themselves. Yes, it is possible for to directly access a private field within the member functions of the class in which the field is defined but you do not want to do so because you would increase the coupling within your class.

Why Use Accessors?

"Good program design seeks to isolate parts of a program from unnecessary, unintended, or otherwise unwanted outside influences. Access modifiers (accessors) provide an explicit and checkable means for the language to control such contacts." [KAN97]

Accessor member functions improve the maintainability of your classes in the following ways:

1. Updating fields. You have single points of update for each field, making it easier to modify and to test. In other words your fields are encapsulated.
2. Obtaining the values of fields. You have complete control over how fields are accessed and by whom.
3. Obtaining the values of constants and the names of classes. By encapsulating the value of constants and of class names in getter member functions when those values/names change you only need to update the value in the getter and not every line of code where the constant/name is used.
4. Initializing fields. The use of lazy initialization ensures that fields are always initialized and that they are initialized only if they are needed.
5. Reduction of the coupling between a subclass and its superclass(es). When subclasses access inherited fields only through their corresponding accessor member functions, it makes it possible to change the implementation of fields in the superclass without affecting any of its subclasses, effectively reducing coupling between them. Accessors reduce the risk of the "fragile base class" where changes in a superclass ripple throughout its subclasses.
6. Encapsulating changes to fields. If the business rules pertaining to one or more fields change you can potentially modify your accessors to provide the same ability as before the change, making it easier for you to respond to the new business rules.
7. Simplification of concurrency issues. [LEA97] points out that setter member functions provide a single place to include a notifyAll if you have waits based on the value of that field. This makes moving to a concurrent solution much easier.
8. Name hiding becomes less of an issue. Although you should avoid name hiding, giving local variables the same names as fields, the use of accessors to always access fields means that you can give local variables any name you want. You do not have to worry about hiding field names because you never access them directly anyway.

When You may not use accessors: The only time that you might want to not use accessors is when execution time is of the utmost importance, however, it is a very rare case indeed that the increased coupling within your application justifies this action.

Naming Accessors

Getter member functions should be given the name . get. + field name, unless the field represents a boolean (true or false) and then the getter is given the name . is. + field name. Setter member functions should be given the name . set. + field name, regardless of the field type [GOS96]; [DES97]. Note that the field name is always in mixed case with the first letter of all words capitalized. This naming convention is used consistently within the JDK and is what is required for beans development.

Examples:

Field	Type	Getter name	Setter name
firstName	string	getFirstName()	setFirstName()
address	Address object	getAddress()	setAddress()
persistent	boolean	isPersistent()	setPersistent()
customerNo	int	getCustomerNo()	setCustomerNo()
orderItems	Array of OrderItem objects	getOrderItems()	setOrderItems()

Advanced Techniques for Accessors

Accessors can be used for more than just getting and setting the values of instance fields. This section discusses how to increase the flexibility of your code by using accessors to:

• Initialize the values of fields
• Access constant values
• Access collections
• Access several fields simultaneously

Lazy Initialization

Variables need to be initialized before they are accessed. There are two lines of thought to initialization: Initialize all variables at the time the object is created (the traditional approach) or initialize at the time of first use. The first approach uses special member functions that are invoked when the object is first created, called constructors. Although this works, it often proves to be error prone. When adding a new variable you can easily forget to update the constructors (An alternative approach is called lazy initialization where fields are initialized by their getter member functions, as shown below (Note how a setter member function is used within the getter member function). Notice the member function checks to see if the branch number is zero, if it is, then it sets it to the appropriate default value.

It is quite common to use lazy initialization for fields that are actually other objects stored in the database. For example, when you create a new inventory item you do not need to fetch whatever inventory item type from the database that you have set as a default. Instead, use lazy initialization to set this value the first time it is accessed so that you only have to read the inventory item type object from the database when and if you need it. This approach is advantageous for objects that have fields that are not regularly accessed. Why incur the overhead of retrieving something from persistent storage if you are not going to use it?

Whenever lazy initialization is used in a getter member function you should document why the default value is what it is, as we saw in the example above. When you do this you take the mystery out of how fields are used in your code, improving both its maintainability and extensibility.

Accessors for Constants

The common Java idiom is to implement constant values as static final fields. This approach makes sense for "constants" that are guaranteed to be stable. For example the class Boolean implements two static final fields called TRUE and FALSE which represents the two instances of that class. It would also make sense for a DAYS_IN_A_WEEK constant whose value probably is never going to change.

However, many so-called business "constants" change over time because the business rule changes. Consider the following example: The Archon Bank of Cardassia (ABC) has always insisted that an account has a minimum balance of $500 if it is to earn interest. To implement this, we could add a static field named MINIMUM_BALANCE to the class Account that would be used in the member functions that calculate interest. Although this would work, it is not flexible. What happens if the business rules change and different kinds of accounts have different minimum balances, perhaps $500 for savings accounts but only $200 for checking accounts? What would happen if the business rule were to change to a $500 minimum balance in the first year, $400 in the second, $300 in the third, and so on? Perhaps the rule will be changed to $500 in the summer but only $250 in the winter? Perhaps a combination of all of these rules will need to be implemented in the future.

The point to be made is that implementing constants as fields is not flexible, a much better solution is to implement constants as getter member functions. In our example above, a static (class) member function called getMinimumBalance() is far more flexible than a static field called MINIMUM_BALANCE because we can implement the various business rules in this member function and subclass it appropriately for various kinds of accounts.

By using accessors for constants we decrease the chance of bugs and at the same time increase the maintainability of our system. When the layout of an account number changes, and we know that it eventually will, chances are that our code will be easier to change because we have both hidden and centralized the information needed to build/break up account numbers.

Accessors for Collections

The main purpose of accessors is to encapsulate the access to fields so as to reduce the coupling within your code. Collections, such as arrays and vectors, being more complex than single value fields naturally need to have more than just the standard getter and setter member function implemented for them. In particular, because you can add and remove to and from collections, accessor member functions need to be included to do so. Add the following accessor member functions where appropriate for a field that is a collection:

Member Function type	Naming convention	Example
Getter for the collection	getCollection()	getOrderItems()
Setter for the collection	setCollection()	setOrderItems()
Insert an object into the collection	insertObject()	insertOrderItem()
Delete an object from the collection	deleteObject()	deleteOrderItem()
Create and add a new object into the collection	newObject()	newOrderItem()

The advantage of this approach is that the collection is fully encapsulated, allowing you to later replace it with another structure, perhaps a linked list or a B-tree.

Accessing Several Fields Simultaneously

One of the strengths of accessor member functions is that they enable you to enforce business rules effectively. Consider for example a class hierarchy of shapes. Each subclass of Shape knows its position via the use of two fields . xPosition and yPosition . and can be moved on the screen on a two-dimensional plane via invoking the member function move(Float xMovement, Float yMovement). For our purposes it does not make sense to move a shape along one axis at a time, instead we will move along both the x and the y axis simultaneously (it is acceptable to pass a value of 0.0 as for either parameter of the move() member function). The implication is that the move() member function should be public, but the member functions setXPosition() and setYPosition() should both be private, being invoked by the move() member function appropriately.

An alternative implementation would be to introduce a setter member function that updates both fields at once, as shown below. The member functions setXPosition() and setYPosition() would still be private so that they may not be invoked directly by external classes or subclasses (you would want to add some documentation, shown below, indicating that they should not be directly invoked).

/** Set the position of the shape */

protected void setPosition(Float x, Float y)

{

	setXPosition(x);

	setYPosition(y);

}

/** Set the x position .  Important: Invoke setPosition(), not this member function. */

private void setXPosition(Float x)

{

	xPosition = x;

}

/** Set the y position of the shape

    Important: Invoke setPosition(), not this member function.

*/

private void setYPosition(Float y)

{

	yPosition = y;

}

Visibility of Accessors

Always strive to make them protected, so that only subclasses can access the fields. Only when an . outside class. needs to access a field should you make the corresponding getter or setter public. Note that it is common that the getter member function be public and the setter protected.

Sometimes you need to make setters private to ensure certain invariants hold. For example, an Order class may have a field representing a collection of OrderItem instances, and a second field called orderTotal which is the total of the entire order. The orderTotal is a convenience field that is the sum or all sub-totals of the ordered items. The only member functions that should update the value of orderTotal are those that manipulate the collection of order items. Assuming that those member functions are all implemented in Order, you should make setOrderTotal() private, even though getOrderTotal() is more than likely public.

Always Initialize Static Fields

Static fields, also known as class fields, should be given valid values because you cannot assume that instances of a class will be created before a static field is accessed.

Standards For Local Variables

A local variable is an object or data item that is defined within the scope of a block, often a member function. The scope of a local variable is the block in which it is defined. The important coding standards for local variables focus on:

• Naming conventions
• Documentation conventions
• Declarations

Naming Local Variables

In general, local variables are named following the same conventions as used for fields, in other words use full English descriptors with the first letter of any non-initial word in uppercase.

For the sake of convenience, however, this naming convention is relaxed for several specific types of local variable:

• Streams
• Loop counters
• Exceptions

Naming Streams

When there is a single input and/or output stream being opened, used, and then closed within a member function the common convention is to use in and out for the names of these streams, respectively [GOS96]. For a stream used for both input and output, the implication is to use the name inOut.

A common alternative to this naming convention, although conflicting with Sun's recommendations, is to use the names inputStream, outputStream, and ioStream instead of in, out, and inOut respectively.

Naming Loop Counters

Because loop counters are a very common use for local variables, and because it was acceptable in C/C++, in Java programming the use of i, j, or k, is acceptable for loop counters [GOS96]. If you use these names for loop counters, use them consistently.

A common alternative is to use names like loopCounter or simply counter, but the problem with this approach is that you often find names like counter1 and counter2 in member functions that require more than one counter. The bottom line is that i, j, k work as counters, they. re quick to type in, and they. re generally accepted.

Naming Exception Objects

Because exception handling is also very common in Java coding the use of the letter e for a generic exception is considered acceptable [GOS96].

Declaring and Documenting Local Variables

There are several conventions regarding the declaration and documentation of local variable in Java. These conventions are:

1. Declare one local variable per line of code. This is consistent with one statement per line of code and makes it possible to document each variable with an inline comment.
2. Document local variables with an inline comment. Inline commenting is a style in which a single line comment, denoted by //, immediately follows a command on the same line of code (this is called an endline comment). You should document what a local variable is used for and where appropriate why it is used, making your code easier to understand.
3. Use local variables for one thing only. Whenever you use a local variable for more than one reason you effectively decrease its cohesion, making it difficult to understand. You also increase the chances of introducing bugs into your code from the unexpected side effects of previous values of a localvariable from earlier in the code. Yes, reusing local variables is more efficient because less memory needs to be allocated, but reusing local variables decreases the maintainability of your code and makes it more fragile. This usually is not worth the small savings from not having to allocate more memory.

General Comments About Declaration

Local variables that are declared between lines of code, for example within the scope of an if statement, can be difficult to find by people not familiar with your code.

One alternative to declaring local variables immediately before their first use is to instead declare them at the top of the code. Because your member functions should be short anyway, see (section 2.4.5 "Write Short, Single Command Lines"), it should not be all that bad having to go to the top of your code to determine what the local variable is all about.

Standards For Parameters to Member Functions

The standards that are important for parameters/arguments to member functions focus on how they are named and how they are documented. The term parameter is used to refer to a member function argument.

Naming Parameters

Parameters should be named following the exact same conventions as for local variables. As with local variables, name hiding is an issue.

Examples:

e

A viable alternative, taken from Smalltalk, is to use the naming conventions for local variables, with the addition of "a" or "an" on the front of the name. The addition of "a" or "an" helps to make the parameter stand out from local variables and fields, and avoids the name hiding problem. This is the preferred approach.

Examples:

anException

Documenting Parameters

Parameters to a member function are documented in the header documentation for the member function using the javadoc @param tag. You should describe:

Use Interfaces for Parameter Types. Instead of specifying a class, such as Object, for the type of a parameter, if appropriate specify an interface, such as Runnable, if appropriate. The advantage is that this approach, depending on the situation, can be more specific (Runnable is more specific than Object), or may potentially be a better way to support polymorphism (instead of insisting on a parameter being an instance of a class in a specific class hierarchy, you specify that it supports a specific interface implying that it only needs to be polymorphically compliant to what you need)

Standards For Classes, Interfaces, Packages and Compilation Units

This chapter concentrates on standards and guidelines for classes, interfaces, packages, and compilation units. A class is a template from which objects are instantiated (created). Classes contain the declaration of fields and member functions. Interfaces are the definition of a common signature, including both member functions and fields, which a class that implements an interface must support. A package is a collection of related classes. Finally, a compilation unit is a source code file in which classes and interfaces are declared. Because Java allows compilation units to be stored in a database an individual compilation unit may not directly relate to a physical source code file.

Standards for Classes

The standards that are important for classes are based on:

• Naming conventions
• Documentation conventions
• Declaration conventions
• The public and protected interface

Naming Classes

The standard Java convention is to use a full English descriptor starting with the first letter capitalized using mixed case for the rest of the name[GOS96]; [AMB98].

Class names shall be in singular form.

Examples:

Customer

Employee

Order

OrderItem

FileStream

String

Documenting a Class

The following information should appear in the documentation comments immediately preceding the definition of a class:

1. The purpose of the class. Developers need to know the general purpose of a class so they can determine whether or not it meets their needs. Make it a habit to document any good things to know about a class, for example is it part of a pattern or are there any interesting limitations to using it [AMB98].
2. Known bugs. If there are any outstanding problems with a class they should be documented so that other developers understand the weaknesses/difficulties with the class. Furthermore, the reason for not fixing the bug should also be documented. Note that if a bug is specific to a single member function then it should be directly associated with the member function instead.
3. The development/maintenance history of the class. It is common practice to include a history table listing dates, authors, and summaries of changes made to a class. The purpose of this is to provide maintenance programmers insight into the modifications made to a class in the past, as well as to document who has done what to a class.
4. Document applicable invariants. An invariant is a set of assertions about an instance or class that must be true at all "stable" times, where a stable time is defined as the period before a member function is invoked on the object/class and immediately after a member function is invoked [MEY88]. By documenting the invariants of a class you provide valuable insight to other developers as to how a class can be used.
5. The concurrency strategy. Any class that implements the interface Runnable should have its concurrency strategy fully described. Concurrent programming is a complex topic that is new for many programmers, therefore you need to invest the extra time to ensure that people can understand your work. It is important to document your concurrency strategy and why you chose that strategy over others. Common concurrency strategies [LEA97] include the following: Synchronized objects, balking objects, guarded objects, versioned objects, concurrency policy controllers, and acceptors.

Class Declarations

One way to make your classes easier to understand is to declare them in a consistent manner. The common approach in Java is to declare a class in the following order:

public member functions

public fields

protected member functions

protected fields

private member functions

private fields

[LAF97] points out that constructors and finalize() should be listed first, presumably because these are the first member functions that another developer will look at first to understand how to use the class. Furthermore, because we have a standard to declare all fields as private, the declaration order really boils down to:

constructors

finalize()

public member functions

protected member functions

private member functions

private fields

Within each grouping of member functions it is common to list them in alphabetical order. Many developers choose to list the static member functions within each grouping first, followed by instance member functions, and then within each of these two sub-groupings list the member functions alphabetically. Both of these approaches are valid, you just need to choose one and stick to it.

Minimize the Public and Protected Interface

One of the fundamentals of object-oriented design is to minimize the public interface of a class. There are several reasons for this:

1. Learnability. To learn how to use a class you should only have to understand its public interface. The smaller the public interface, the easier a class is to learn.
2. Reduced coupling. Whenever the instance of one class sends a message to an instance of another class, or directly to the class itself, the two classes become coupled. Minimizing the public interface implies that you are minimizing the opportunities for coupling.
3. Greater flexibility. This is directly related to coupling. Whenever you want to change the way that a member function in your public interface is implemented, perhaps you want to modify what the member function returns, then you potentially have to modify any code that invokes the member function. The smaller the public interface the greater the encapsulation and therefore the greater your flexibility.

It is clear that it is worth your while to minimize the public interface, but often what is not so clear is that you also want to minimize the protected interface as well. The basic idea is that from the point of view of a subclass, the protected interfaces of all of its superclasses are effectively public. Any member function in the protected interface can be invoked by a subclass. Therefore, you want to minimize the protected interface of a class for the same reasons that you want to minimize the public interface.

Define The Public Interface First. Most experienced developers define the public interface of a class before they begin coding it. First, if you do not know what services/behaviors a class will perform, then you still have some design work to do. Second, it enables them to stub out the class quickly so that other developers who rely on it can at least work with the stub until the "real" class has been developed. Third, this approach provides you with an initial framework around which to build your class.

Standards for Interfaces

The standards that are important for interfaces are based on:

• Naming conventions
• Documentation conventions

Naming Interfaces

The Java convention is to name interfaces using mixed case with the first letter of each word capitalized. The preferred Java convention for the name of an interface is to use a descriptive adjective, such as Runnable or Cloneable, although descriptive nouns, such as Singleton or DataInput, are also common [GOS96].

Alternative:

Prefix the letter . I. to the interface name. [COA97] suggest appending the letter . I. to the front of an interface names, resulting in names like ISingleton or IRunnable. This approach helps to distinguish interface names from class and package names. I like this potential naming convention for the simple fact that it makes your class diagrams, sometimes referred to as object models, easier to read. The main disadvantage is that the existing interfaces, such as Runnable, are not named using this approach. This interface naming convention is also popular for Microsoft. s COM/DCOM architecture.

Documenting Interfaces

The following information should appear in the documentation comments immediately preceding the definition of an interface:

1. The purpose. Before other developers will use an interface, they need to understand the concept that it encapsulates. In other words, they need to know its purpose. A really good test of whether or not you need to define an interface is whether or not you can easily describe its purpose. If you have difficulties describing it, then chances are pretty good you do not need the interface to begin with. Because the concept of interfaces is new to Java, people are not yet experienced in their appropriate use and they are likely to overuse them because they are new.
2. How it should and should not be used. Developers need to know both how an interface is to be used, as well as how it should not be used [COA97].

Because the signature for member functions is defined in an interface, for each member function signature you should follow the member function documentation conventions discussed in chapter 2.

Standards for Packages

The standards that are important for packages are based on:

• Naming conventions
• Documentation conventions

Naming Packages

There are several rules associated with the naming of packages. In order, these rules are:

1. Identifiers are separated by periods. To make package names more readable, Sun suggests that the identifiers in package names be separated by periods. For example, the package name java.awt is comprised of two identifiers, java and awt.
2. The standard java distribution packages from Sun begin with the identifier . java. . Sun has reserved this right so that the standard java packages are named in a consistent manner regardless of the vendor of your Java development environment.
3. Local package names begin with an identifier that is not all upper case. Local packages are ones that are used internally within your organization and that will not be distributed to other organizations. Examples of these package names include persistence.mapping.relational and interface.screens.
4. Global package names begin with the reversed Internet domain name for your organization. A package that is to be distributed to multiple organizations should include the name of the originating organization. s domain name, with the top-level domain type capitalized. For example, to distribute the previous packages, they would be named com.rational.www.persistence.mapping.relational and com.rational.www.interface.screens.0

Documenting Packages

You should maintain one or more external documents that describe the purpose of the packages developed by your organization. For each package you should document:

1. The rationale for the package. Other developers need to know what a package is all about so that they can determine whether or not they want to use it, and if it is a shared package whether or not they want to enhance or extend it.
2. The classes in the package. Include a list of the classes and interfaces in the package with a brief, one-line description of each so that other developers know what the package contains.

Tip: Create an HTML file, using the name of the package, and put it in the appropriate directory for the package. The file shall be postfixed with .html.

Standards for Compilation Units

The standards and guidelines for compilation units are based on:

• Naming conventions
• Documentation conventions

Naming Compilation Units

A compilation unit, in this case a source code file, should be given the name of the primary class or interface that is declared within it. Use the same name for the package/class for the file name, using the same case. The extension .java should be postfixed to the file name.

Examples:

Customer.java

Singleton.java

SavingsAccount.java

Documenting Compilation Units

Although you should strive to have only one class or interface declaration per file, it sometimes makes sense to define several classes (or interfaces) in the same file. A general rule of thumb is that if the sole purpose of class B is to encapsulate functionality that is needed only by class A then it makes sense that class B appear in the same source code file as class A. As a result, the following documentation conventions apply to a source code file, and not specifically to a class:

1. For files with several classes, list each class. If a file contains more than one class you should provide a list of the classes and a brief description for each.
2. The file name and/or identifying information. The name of the file should be included at the top of it. The advantage is that if the code is printed you know what the source file for the code is.
3. Copyright information. If applicable you should indicate any copyright information for the file. It is common to indicate the year of the copyright and the name of the individual/organization that holds the copyright. Note that the code author may not be the holder of the copyright.

Error Handling and Exceptions

The general philosophy is to use exceptions only for errors: logic and programming errors, configuration errors, corrupted data, resource exhaustion, etc. The general rule is that the systems in normal condition and in the absence of overload or hardware failure should not raise any exceptions.

Use exceptions to handle logic and programming errors, configuration errors, corrupted data, resource exhaustion. Report exceptions by the appropriate logging mechanism as early as possible, including at the point of raise.

Minimize the number of exceptions exported from a given abstraction.

In large systems, having to handle a large number of exceptions at each level makes the code difficult to read and to maintain. Sometimes the exception processing dwarfs the normal processing.

There are several ways to minimize the number of exceptions:

• Export only a few exceptions but provide "diagnosis" primitives that allow querying the faulty abstraction or the bad object for more detailed information about the nature of the problem that occurred.

• Add "exceptional" states to the objects, and provide primitives to check explicitly the validity of the objects.

Do not use exceptions for frequent, anticipated events.

There are several inconveniences in using exceptions to represent conditions that are not clearly errors:

• It is confusing.
• It usually forces some disruption in the flow of control that is more difficult to understand and to maintain.
• It makes the code more painful to debug, since most source-level debuggers flag all exceptions by default.

For instance, do not use an exception as some form of extra value returned by a function (like Value_Not_Found in a search); use a procedure with an "out" parameter, or introduce a special value meaning Not_Found, or pack the returned type in a record with a discriminant Not_Found.

Do not use exceptions to implement control structures.

This is a special case of the previous rule: exceptions should not be used as a form of "goto" statement.

Make sure status codes have an appropriate value.

When using status code returned by subprograms as an "out" parameter, always make sure a value is assigned to the "out" parameter by making this the first executable statement in the subprogram body. Systematically make all statuses a success by default or a failure by default. Think of all possible exits from the subprogram, including exception handlers.

Perform safety checks locally; do not expect your client to do so.

That is, if a subprogram might produce erroneous output unless given proper input, install code in the subprogram to detect and report invalid input in a controlled manner. Do not rely on a comment that tells the client to pass proper values. It is virtually guaranteed that sooner or later that comment will be ignored, resulting in hard-to-debug errors if the invalid parameters are not detected.

Miscellaneous Standards and Issues

This chapter describes several standards/guidelines that are important, but that are general enough that they need their own chapter.

Reuse

Any Java class library or package that you purchase/reuse from an external source should be certified as 100% pure Java [SUN97]. By enforcing this standard you are guaranteed that what you are reusing will work on all platforms that you choose to deploy it on. You can obtain Java classes, packages, or applets from a variety of sources, either a third-party development company that specializes in Java libraries or another division or project team within your organization.

Importing Classes

The import statement allows the use of wildcards when indicating the names of classes. For example, the statement

import java.awt.*;

brings in all of the classes in the package java.awt at once. Actually, that. s not completely true. What really happens is that every class that you use from the java.awt package will be brought into your code when it is compiled, classes that you do not use will not be. Although this sounds like a good feature, it reduces the readability of your code. A better approach is to fully qualify the name of the classes that your code uses [LAF97]; [VIS96]. A better way to import classes is shown in the example below:

import java.awt.Color;

import java.awt.Button;

import java.awt.Container;

Optimizing Java Code

Optimizing your code is one of the last things that programmers should be thinking about, not one of the first. You leave optimization to the end because you want to optimize only the code that needs it. Very often a small percentage of your code results in the vast majority of the processing time, and this is the code that you should be optimizing. A classic mistake made by inexperienced programmers is to try to optimize all of their code, even code that already runs fast enough

Do not waste your time optimizing code that nobody cares about!

What should you look for when optimizing code? [KOE97] points out that the most important factors are fixed overhead and performance on large inputs. The reason for this is simple: fixed overhead dominates the runtime speed for small inputs and the algorithm dominates for large inputs. His rule of thumb is that a program that works well for both small and large inputs will likely work well for medium-sized inputs.

Developers who have to write software that work on several hardware platforms and/or operating systems need to be aware of idiosyncrasies in the various platforms. Operations that might appear to take a particular amount of time, such as the way that memory and buffers are handled, often show substantial variations between platforms. It is common to find that you need to optimize your code differently depending on the platform.

Another issue to be aware of when optimizing code is the priorities of your users because depending on the context people will be sensitive to particular delays. For example, your users will likely be happier with a screen that draws itself immediately and then takes eight seconds to load data than with a screen that draws itself after taking five seconds to load data. In other words most users are willing to wait a little longer as long as they. re given immediate feedback, important knowledge to have when optimizing your code.

You do not always need to make your code run faster to optimize it in the eyes of your users.

Although optimization may mean the difference between the success and failure of your application, never forget that it is far more important to get your code to work properly. Never forget that slow software that works is always preferable to fast software that does not.

Writing Java Test Harnesses

Object-oriented testing is a critical topic that has been all but ignored by the object development community. The reality is that either you or someone else will have to test the software that you write, regardless of the language that you have chosen to work in. A test harness is the collection of member functions, some embedded in the classes themselves (this is called built-in tests) and some in specialized testing classes, that is used to test your application.

1. Prefix all testing member function names with . test. . This allows you to quickly find all the testing member functions in your code. The advantage of prefixing the name of test member functions with . test. is that it allows you to easily strip your testing member functions out of your source code before compiling the production version of it.
2. Name all member function test member functions consistently. Method testing is the act of verifying that a single member function performs as defined. All member function test member functions should be named following the format . testMemberFunctionNameForTestName. . For example, the test harness member functions to test withdrawFunds() would include testWithdrawFundsForInsufficientFunds() and testWithdrawFundsForSmallWithdrawal(). If you have a series of tests for withdrawFunds() you may choose to write a member function called testWithdrawFunds() that invokes all of them.
3. Name all class test member functions consistently. Class testing is the act of verifying that a single class performs as defined. All class test member functions should be named following the format . testSelfForTestName. . For example, the test harness member functions to test the Account class testSelfForSimultaneousAccess() and testSelfForReporting().
4. Create a single point for invoking the tests for a class. Develop a static member function called testSelf() that invokes all class testing and method testing member functions.

Document your test harness member functions. Document your test harness member functions. The documentation should include a description of the test as well as the expected results of the test.